home *** CD-ROM | disk | FTP | other *** search
/ Scene Storm / Scene Storm - Volume 1.iso / coding / tools / gcc / gcc270_src.lha / gcc-2.7.0-amiga / gcc.info-10 < prev    next >
Encoding:
GNU Info File  |  1995-06-16  |  49.4 KB  |  1,147 lines

  1. This is Info file gcc.info, produced by Makeinfo-1.55 from the input
  2. file gcc.texi.
  3.  
  4.    This file documents the use and the internals of the GNU compiler.
  5.  
  6.    Published by the Free Software Foundation 59 Temple Place - Suite 330
  7. Boston, MA 02111-1307 USA
  8.  
  9.    Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995 Free Software
  10. Foundation, Inc.
  11.  
  12.    Permission is granted to make and distribute verbatim copies of this
  13. manual provided the copyright notice and this permission notice are
  14. preserved on all copies.
  15.  
  16.    Permission is granted to copy and distribute modified versions of
  17. this manual under the conditions for verbatim copying, provided also
  18. that the sections entitled "GNU General Public License," "Funding for
  19. Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are
  20. included exactly as in the original, and provided that the entire
  21. resulting derived work is distributed under the terms of a permission
  22. notice identical to this one.
  23.  
  24.    Permission is granted to copy and distribute translations of this
  25. manual into another language, under the above conditions for modified
  26. versions, except that the sections entitled "GNU General Public
  27. License," "Funding for Free Software," and "Protect Your Freedom--Fight
  28. `Look And Feel'", and this permission notice, may be included in
  29. translations approved by the Free Software Foundation instead of in the
  30. original English.
  31.  
  32. 
  33. File: gcc.info,  Node: Explicit Reg Vars,  Next: Alternate Keywords,  Prev: Asm Labels,  Up: C Extensions
  34.  
  35. Variables in Specified Registers
  36. ================================
  37.  
  38.    GNU C allows you to put a few global variables into specified
  39. hardware registers.  You can also specify the register in which an
  40. ordinary register variable should be allocated.
  41.  
  42.    * Global register variables reserve registers throughout the program.
  43.      This may be useful in programs such as programming language
  44.      interpreters which have a couple of global variables that are
  45.      accessed very often.
  46.  
  47.    * Local register variables in specific registers do not reserve the
  48.      registers.  The compiler's data flow analysis is capable of
  49.      determining where the specified registers contain live values, and
  50.      where they are available for other uses.
  51.  
  52.      These local variables are sometimes convenient for use with the
  53.      extended `asm' feature (*note Extended Asm::.), if you want to
  54.      write one output of the assembler instruction directly into a
  55.      particular register.  (This will work provided the register you
  56.      specify fits the constraints specified for that operand in the
  57.      `asm'.)
  58.  
  59. * Menu:
  60.  
  61. * Global Reg Vars::
  62. * Local Reg Vars::
  63.  
  64. 
  65. File: gcc.info,  Node: Global Reg Vars,  Next: Local Reg Vars,  Up: Explicit Reg Vars
  66.  
  67. Defining Global Register Variables
  68. ----------------------------------
  69.  
  70.    You can define a global register variable in GNU C like this:
  71.  
  72.      register int *foo asm ("a5");
  73.  
  74. Here `a5' is the name of the register which should be used.  Choose a
  75. register which is normally saved and restored by function calls on your
  76. machine, so that library routines will not clobber it.
  77.  
  78.    Naturally the register name is cpu-dependent, so you would need to
  79. conditionalize your program according to cpu type.  The register `a5'
  80. would be a good choice on a 68000 for a variable of pointer type.  On
  81. machines with register windows, be sure to choose a "global" register
  82. that is not affected magically by the function call mechanism.
  83.  
  84.    In addition, operating systems on one type of cpu may differ in how
  85. they name the registers; then you would need additional conditionals.
  86. For example, some 68000 operating systems call this register `%a5'.
  87.  
  88.    Eventually there may be a way of asking the compiler to choose a
  89. register automatically, but first we need to figure out how it should
  90. choose and how to enable you to guide the choice.  No solution is
  91. evident.
  92.  
  93.    Defining a global register variable in a certain register reserves
  94. that register entirely for this use, at least within the current
  95. compilation.  The register will not be allocated for any other purpose
  96. in the functions in the current compilation.  The register will not be
  97. saved and restored by these functions.  Stores into this register are
  98. never deleted even if they would appear to be dead, but references may
  99. be deleted or moved or simplified.
  100.  
  101.    It is not safe to access the global register variables from signal
  102. handlers, or from more than one thread of control, because the system
  103. library routines may temporarily use the register for other things
  104. (unless you recompile them specially for the task at hand).
  105.  
  106.    It is not safe for one function that uses a global register variable
  107. to call another such function `foo' by way of a third function `lose'
  108. that was compiled without knowledge of this variable (i.e. in a
  109. different source file in which the variable wasn't declared).  This is
  110. because `lose' might save the register and put some other value there.
  111. For example, you can't expect a global register variable to be
  112. available in the comparison-function that you pass to `qsort', since
  113. `qsort' might have put something else in that register.  (If you are
  114. prepared to recompile `qsort' with the same global register variable,
  115. you can solve this problem.)
  116.  
  117.    If you want to recompile `qsort' or other source files which do not
  118. actually use your global register variable, so that they will not use
  119. that register for any other purpose, then it suffices to specify the
  120. compiler option `-ffixed-REG'.  You need not actually add a global
  121. register declaration to their source code.
  122.  
  123.    A function which can alter the value of a global register variable
  124. cannot safely be called from a function compiled without this variable,
  125. because it could clobber the value the caller expects to find there on
  126. return.  Therefore, the function which is the entry point into the part
  127. of the program that uses the global register variable must explicitly
  128. save and restore the value which belongs to its caller.
  129.  
  130.    On most machines, `longjmp' will restore to each global register
  131. variable the value it had at the time of the `setjmp'.  On some
  132. machines, however, `longjmp' will not change the value of global
  133. register variables.  To be portable, the function that called `setjmp'
  134. should make other arrangements to save the values of the global register
  135. variables, and to restore them in a `longjmp'.  This way, the same
  136. thing will happen regardless of what `longjmp' does.
  137.  
  138.    All global register variable declarations must precede all function
  139. definitions.  If such a declaration could appear after function
  140. definitions, the declaration would be too late to prevent the register
  141. from being used for other purposes in the preceding functions.
  142.  
  143.    Global register variables may not have initial values, because an
  144. executable file has no means to supply initial contents for a register.
  145.  
  146.    On the Sparc, there are reports that g3 ... g7 are suitable
  147. registers, but certain library functions, such as `getwd', as well as
  148. the subroutines for division and remainder, modify g3 and g4.  g1 and
  149. g2 are local temporaries.
  150.  
  151.    On the 68000, a2 ... a5 should be suitable, as should d2 ... d7.  Of
  152. course, it will not do to use more than a few of those.
  153.  
  154. 
  155. File: gcc.info,  Node: Local Reg Vars,  Prev: Global Reg Vars,  Up: Explicit Reg Vars
  156.  
  157. Specifying Registers for Local Variables
  158. ----------------------------------------
  159.  
  160.    You can define a local register variable with a specified register
  161. like this:
  162.  
  163.      register int *foo asm ("a5");
  164.  
  165. Here `a5' is the name of the register which should be used.  Note that
  166. this is the same syntax used for defining global register variables,
  167. but for a local variable it would appear within a function.
  168.  
  169.    Naturally the register name is cpu-dependent, but this is not a
  170. problem, since specific registers are most often useful with explicit
  171. assembler instructions (*note Extended Asm::.).  Both of these things
  172. generally require that you conditionalize your program according to cpu
  173. type.
  174.  
  175.    In addition, operating systems on one type of cpu may differ in how
  176. they name the registers; then you would need additional conditionals.
  177. For example, some 68000 operating systems call this register `%a5'.
  178.  
  179.    Eventually there may be a way of asking the compiler to choose a
  180. register automatically, but first we need to figure out how it should
  181. choose and how to enable you to guide the choice.  No solution is
  182. evident.
  183.  
  184.    Defining such a register variable does not reserve the register; it
  185. remains available for other uses in places where flow control determines
  186. the variable's value is not live.  However, these registers are made
  187. unavailable for use in the reload pass.  I would not be surprised if
  188. excessive use of this feature leaves the compiler too few available
  189. registers to compile certain functions.
  190.  
  191. 
  192. File: gcc.info,  Node: Alternate Keywords,  Next: Incomplete Enums,  Prev: Explicit Reg Vars,  Up: C Extensions
  193.  
  194. Alternate Keywords
  195. ==================
  196.  
  197.    The option `-traditional' disables certain keywords; `-ansi'
  198. disables certain others.  This causes trouble when you want to use GNU C
  199. extensions, or ANSI C features, in a general-purpose header file that
  200. should be usable by all programs, including ANSI C programs and
  201. traditional ones.  The keywords `asm', `typeof' and `inline' cannot be
  202. used since they won't work in a program compiled with `-ansi', while
  203. the keywords `const', `volatile', `signed', `typeof' and `inline' won't
  204. work in a program compiled with `-traditional'.
  205.  
  206.    The way to solve these problems is to put `__' at the beginning and
  207. end of each problematical keyword.  For example, use `__asm__' instead
  208. of `asm', `__const__' instead of `const', and `__inline__' instead of
  209. `inline'.
  210.  
  211.    Other C compilers won't accept these alternative keywords; if you
  212. want to compile with another compiler, you can define the alternate
  213. keywords as macros to replace them with the customary keywords.  It
  214. looks like this:
  215.  
  216.      #ifndef __GNUC__
  217.      #define __asm__ asm
  218.      #endif
  219.  
  220.    `-pedantic' causes warnings for many GNU C extensions.  You can
  221. prevent such warnings within one expression by writing `__extension__'
  222. before the expression.  `__extension__' has no effect aside from this.
  223.  
  224. 
  225. File: gcc.info,  Node: Incomplete Enums,  Next: Function Names,  Prev: Alternate Keywords,  Up: C Extensions
  226.  
  227. Incomplete `enum' Types
  228. =======================
  229.  
  230.    You can define an `enum' tag without specifying its possible values.
  231. This results in an incomplete type, much like what you get if you write
  232. `struct foo' without describing the elements.  A later declaration
  233. which does specify the possible values completes the type.
  234.  
  235.    You can't allocate variables or storage using the type while it is
  236. incomplete.  However, you can work with pointers to that type.
  237.  
  238.    This extension may not be very useful, but it makes the handling of
  239. `enum' more consistent with the way `struct' and `union' are handled.
  240.  
  241.    This extension is not supported by GNU C++.
  242.  
  243. 
  244. File: gcc.info,  Node: Function Names,  Prev: Incomplete Enums,  Up: C Extensions
  245.  
  246. Function Names as Strings
  247. =========================
  248.  
  249.    GNU CC predefines two string variables to be the name of the current
  250. function.  The variable `__FUNCTION__' is the name of the function as
  251. it appears in the source.  The variable `__PRETTY_FUNCTION__' is the
  252. name of the function pretty printed in a language specific fashion.
  253.  
  254.    These names are always the same in a C function, but in a C++
  255. function they may be different.  For example, this program:
  256.  
  257.      extern "C" {
  258.      extern int printf (char *, ...);
  259.      }
  260.      
  261.      class a {
  262.       public:
  263.        sub (int i)
  264.          {
  265.            printf ("__FUNCTION__ = %s\n", __FUNCTION__);
  266.            printf ("__PRETTY_FUNCTION__ = %s\n", __PRETTY_FUNCTION__);
  267.          }
  268.      };
  269.      
  270.      int
  271.      main (void)
  272.      {
  273.        a ax;
  274.        ax.sub (0);
  275.        return 0;
  276.      }
  277.  
  278. gives this output:
  279.  
  280.      __FUNCTION__ = sub
  281.      __PRETTY_FUNCTION__ = int  a::sub (int)
  282.  
  283. 
  284. File: gcc.info,  Node: C++ Extensions,  Next: Trouble,  Prev: C Extensions,  Up: Top
  285.  
  286. Extensions to the C++ Language
  287. ******************************
  288.  
  289.    The GNU compiler provides these extensions to the C++ language (and
  290. you can also use most of the C language extensions in your C++
  291. programs).  If you want to write code that checks whether these
  292. features are available, you can test for the GNU compiler the same way
  293. as for C programs: check for a predefined macro `__GNUC__'.  You can
  294. also use `__GNUG__' to test specifically for GNU C++ (*note Standard
  295. Predefined Macros: (cpp.info)Standard Predefined.).
  296.  
  297. * Menu:
  298.  
  299. * Naming Results::      Giving a name to C++ function return values.
  300. * Min and Max::        C++ Minimum and maximum operators.
  301. * Destructors and Goto:: Goto is safe to use in C++ even when destructors
  302.                            are needed.
  303. * C++ Interface::       You can use a single C++ header file for both
  304.                          declarations and definitions.
  305. * Template Instantiation:: Methods for ensuring that exactly one copy of
  306.                          each needed template instantiation is emitted.
  307. * C++ Signatures::    You can specify abstract types to get subtype
  308.              polymorphism independent from inheritance.
  309.  
  310. 
  311. File: gcc.info,  Node: Naming Results,  Next: Min and Max,  Up: C++ Extensions
  312.  
  313. Named Return Values in C++
  314. ==========================
  315.  
  316.    GNU C++ extends the function-definition syntax to allow you to
  317. specify a name for the result of a function outside the body of the
  318. definition, in C++ programs:
  319.  
  320.      TYPE
  321.      FUNCTIONNAME (ARGS) return RESULTNAME;
  322.      {
  323.        ...
  324.        BODY
  325.        ...
  326.      }
  327.  
  328.    You can use this feature to avoid an extra constructor call when a
  329. function result has a class type.  For example, consider a function
  330. `m', declared as `X v = m ();', whose result is of class `X':
  331.  
  332.      X
  333.      m ()
  334.      {
  335.        X b;
  336.        b.a = 23;
  337.        return b;
  338.      }
  339.  
  340.    Although `m' appears to have no arguments, in fact it has one
  341. implicit argument: the address of the return value.  At invocation, the
  342. address of enough space to hold `v' is sent in as the implicit argument.
  343. Then `b' is constructed and its `a' field is set to the value 23.
  344. Finally, a copy constructor (a constructor of the form `X(X&)') is
  345. applied to `b', with the (implicit) return value location as the
  346. target, so that `v' is now bound to the return value.
  347.  
  348.    But this is wasteful.  The local `b' is declared just to hold
  349. something that will be copied right out.  While a compiler that
  350. combined an "elision" algorithm with interprocedural data flow analysis
  351. could conceivably eliminate all of this, it is much more practical to
  352. allow you to assist the compiler in generating efficient code by
  353. manipulating the return value explicitly, thus avoiding the local
  354. variable and copy constructor altogether.
  355.  
  356.    Using the extended GNU C++ function-definition syntax, you can avoid
  357. the temporary allocation and copying by naming `r' as your return value
  358. at the outset, and assigning to its `a' field directly:
  359.  
  360.      X
  361.      m () return r;
  362.      {
  363.        r.a = 23;
  364.      }
  365.  
  366. The declaration of `r' is a standard, proper declaration, whose effects
  367. are executed *before* any of the body of `m'.
  368.  
  369.    Functions of this type impose no additional restrictions; in
  370. particular, you can execute `return' statements, or return implicitly by
  371. reaching the end of the function body ("falling off the edge").  Cases
  372. like
  373.  
  374.      X
  375.      m () return r (23);
  376.      {
  377.        return;
  378.      }
  379.  
  380. (or even `X m () return r (23); { }') are unambiguous, since the return
  381. value `r' has been initialized in either case.  The following code may
  382. be hard to read, but also works predictably:
  383.  
  384.      X
  385.      m () return r;
  386.      {
  387.        X b;
  388.        return b;
  389.      }
  390.  
  391.    The return value slot denoted by `r' is initialized at the outset,
  392. but the statement `return b;' overrides this value.  The compiler deals
  393. with this by destroying `r' (calling the destructor if there is one, or
  394. doing nothing if there is not), and then reinitializing `r' with `b'.
  395.  
  396.    This extension is provided primarily to help people who use
  397. overloaded operators, where there is a great need to control not just
  398. the arguments, but the return values of functions.  For classes where
  399. the copy constructor incurs a heavy performance penalty (especially in
  400. the common case where there is a quick default constructor), this is a
  401. major savings.  The disadvantage of this extension is that you do not
  402. control when the default constructor for the return value is called: it
  403. is always called at the beginning.
  404.  
  405. 
  406. File: gcc.info,  Node: Min and Max,  Next: Destructors and Goto,  Prev: Naming Results,  Up: C++ Extensions
  407.  
  408. Minimum and Maximum Operators in C++
  409. ====================================
  410.  
  411.    It is very convenient to have operators which return the "minimum"
  412. or the "maximum" of two arguments.  In GNU C++ (but not in GNU C),
  413.  
  414. `A <? B'
  415.      is the "minimum", returning the smaller of the numeric values A
  416.      and B;
  417.  
  418. `A >? B'
  419.      is the "maximum", returning the larger of the numeric values A and
  420.      B.
  421.  
  422.    These operations are not primitive in ordinary C++, since you can
  423. use a macro to return the minimum of two things in C++, as in the
  424. following example.
  425.  
  426.      #define MIN(X,Y) ((X) < (Y) ? : (X) : (Y))
  427.  
  428. You might then use `int min = MIN (i, j);' to set MIN to the minimum
  429. value of variables I and J.
  430.  
  431.    However, side effects in `X' or `Y' may cause unintended behavior.
  432. For example, `MIN (i++, j++)' will fail, incrementing the smaller
  433. counter twice.  A GNU C extension allows you to write safe macros that
  434. avoid this kind of problem (*note Naming an Expression's Type: Naming
  435. Types.).  However, writing `MIN' and `MAX' as macros also forces you to
  436. use function-call notation notation for a fundamental arithmetic
  437. operation.  Using GNU C++ extensions, you can write `int min = i <? j;'
  438. instead.
  439.  
  440.    Since `<?' and `>?' are built into the compiler, they properly
  441. handle expressions with side-effects;  `int min = i++ <? j++;' works
  442. correctly.
  443.  
  444. 
  445. File: gcc.info,  Node: Destructors and Goto,  Next: C++ Interface,  Prev: Min and Max,  Up: C++ Extensions
  446.  
  447. `goto' and Destructors in GNU C++
  448. =================================
  449.  
  450.    In C++ programs, you can safely use the `goto' statement.  When you
  451. use it to exit a block which contains aggregates requiring destructors,
  452. the destructors will run before the `goto' transfers control.  (In ANSI
  453. C++, `goto' is restricted to targets within the current block.)
  454.  
  455.    The compiler still forbids using `goto' to *enter* a scope that
  456. requires constructors.
  457.  
  458. 
  459. File: gcc.info,  Node: C++ Interface,  Next: Template Instantiation,  Prev: Destructors and Goto,  Up: C++ Extensions
  460.  
  461. Declarations and Definitions in One Header
  462. ==========================================
  463.  
  464.    C++ object definitions can be quite complex.  In principle, your
  465. source code will need two kinds of things for each object that you use
  466. across more than one source file.  First, you need an "interface"
  467. specification, describing its structure with type declarations and
  468. function prototypes.  Second, you need the "implementation" itself.  It
  469. can be tedious to maintain a separate interface description in a header
  470. file, in parallel to the actual implementation.  It is also dangerous,
  471. since separate interface and implementation definitions may not remain
  472. parallel.
  473.  
  474.    With GNU C++, you can use a single header file for both purposes.
  475.  
  476.      *Warning:* The mechanism to specify this is in transition.  For the
  477.      nonce, you must use one of two `#pragma' commands; in a future
  478.      release of GNU C++, an alternative mechanism will make these
  479.      `#pragma' commands unnecessary.
  480.  
  481.    The header file contains the full definitions, but is marked with
  482. `#pragma interface' in the source code.  This allows the compiler to
  483. use the header file only as an interface specification when ordinary
  484. source files incorporate it with `#include'.  In the single source file
  485. where the full implementation belongs, you can use either a naming
  486. convention or `#pragma implementation' to indicate this alternate use
  487. of the header file.
  488.  
  489. `#pragma interface'
  490. `#pragma interface "SUBDIR/OBJECTS.h"'
  491.      Use this directive in *header files* that define object classes,
  492.      to save space in most of the object files that use those classes.
  493.      Normally, local copies of certain information (backup copies of
  494.      inline member functions, debugging information, and the internal
  495.      tables that implement virtual functions) must be kept in each
  496.      object file that includes class definitions.  You can use this
  497.      pragma to avoid such duplication.  When a header file containing
  498.      `#pragma interface' is included in a compilation, this auxiliary
  499.      information will not be generated (unless the main input source
  500.      file itself uses `#pragma implementation').  Instead, the object
  501.      files will contain references to be resolved at link time.
  502.  
  503.      The second form of this directive is useful for the case where you
  504.      have multiple headers with the same name in different directories.
  505.      If you use this form, you must specify the same string to `#pragma
  506.      implementation'.
  507.  
  508. `#pragma implementation'
  509. `#pragma implementation "OBJECTS.h"'
  510.      Use this pragma in a *main input file*, when you want full output
  511.      from included header files to be generated (and made globally
  512.      visible).  The included header file, in turn, should use `#pragma
  513.      interface'.  Backup copies of inline member functions, debugging
  514.      information, and the internal tables used to implement virtual
  515.      functions are all generated in implementation files.
  516.  
  517.      If you use `#pragma implementation' with no argument, it applies to
  518.      an include file with the same basename(1) as your source file.
  519.      For example, in `allclass.cc', `#pragma implementation' by itself
  520.      is equivalent to `#pragma implementation "allclass.h"'.
  521.  
  522.      In versions of GNU C++ prior to 2.6.0 `allclass.h' was treated as
  523.      an implementation file whenever you would include it from
  524.      `allclass.cc' even if you never specified `#pragma
  525.      implementation'.  This was deemed to be more trouble than it was
  526.      worth, however, and disabled.
  527.  
  528.      If you use an explicit `#pragma implementation', it must appear in
  529.      your source file *before* you include the affected header files.
  530.  
  531.      Use the string argument if you want a single implementation file to
  532.      include code from multiple header files.  (You must also use
  533.      `#include' to include the header file; `#pragma implementation'
  534.      only specifies how to use the file--it doesn't actually include
  535.      it.)
  536.  
  537.      There is no way to split up the contents of a single header file
  538.      into multiple implementation files.
  539.  
  540.    `#pragma implementation' and `#pragma interface' also have an effect
  541. on function inlining.
  542.  
  543.    If you define a class in a header file marked with `#pragma
  544. interface', the effect on a function defined in that class is similar to
  545. an explicit `extern' declaration--the compiler emits no code at all to
  546. define an independent version of the function.  Its definition is used
  547. only for inlining with its callers.
  548.  
  549.    Conversely, when you include the same header file in a main source
  550. file that declares it as `#pragma implementation', the compiler emits
  551. code for the function itself; this defines a version of the function
  552. that can be found via pointers (or by callers compiled without
  553. inlining).  If all calls to the function can be inlined, you can avoid
  554. emitting the function by compiling with `-fno-implement-inlines'.  If
  555. any calls were not inlined, you will get linker errors.
  556.  
  557.    ---------- Footnotes ----------
  558.  
  559.    (1)  A file's "basename" was the name stripped of all leading path
  560. information and of trailing suffixes, such as `.h' or `.C' or `.cc'.
  561.  
  562. 
  563. File: gcc.info,  Node: Template Instantiation,  Next: C++ Signatures,  Prev: C++ Interface,  Up: C++ Extensions
  564.  
  565. Where's the Template?
  566. =====================
  567.  
  568.    C++ templates are the first language feature to require more
  569. intelligence from the environment than one usually finds on a UNIX
  570. system.  Somehow the compiler and linker have to make sure that each
  571. template instance occurs exactly once in the executable if it is needed,
  572. and not at all otherwise.  There are two basic approaches to this
  573. problem, which I will refer to as the Borland model and the Cfront
  574. model.
  575.  
  576. Borland model
  577.      Borland C++ solved the template instantiation problem by adding
  578.      the code equivalent of common blocks to their linker; template
  579.      instances are emitted in each translation unit that uses them, and
  580.      they are collapsed together at run time.  The advantage of this
  581.      model is that the linker only has to consider the object files
  582.      themselves; there is no external complexity to worry about.  This
  583.      disadvantage is that compilation time is increased because the
  584.      template code is being compiled repeatedly.  Code written for this
  585.      model tends to include definitions of all member templates in the
  586.      header file, since they must be seen to be compiled.
  587.  
  588. Cfront model
  589.      The AT&T C++ translator, Cfront, solved the template instantiation
  590.      problem by creating the notion of a template repository, an
  591.      automatically maintained place where template instances are
  592.      stored.  As individual object files are built, notes are placed in
  593.      the repository to record where templates and potential type
  594.      arguments were seen so that the subsequent instantiation step
  595.      knows where to find them.  At link time, any needed instances are
  596.      generated and linked in.  The advantages of this model are more
  597.      optimal compilation speed and the ability to use the system
  598.      linker; to implement the Borland model a compiler vendor also
  599.      needs to replace the linker.  The disadvantages are vastly
  600.      increased complexity, and thus potential for error; theoretically,
  601.      this should be just as transparent, but in practice it has been
  602.      very difficult to build multiple programs in one directory and one
  603.      program in multiple directories using Cfront.  Code written for
  604.      this model tends to separate definitions of non-inline member
  605.      templates into a separate file, which is magically found by the
  606.      link preprocessor when a template needs to be instantiated.
  607.  
  608.    Currently, g++ implements neither automatic model.  The g++ team
  609. hopes to have a repository working for 2.7.0.  In the mean time, you
  610. have three options for dealing with template instantiations:
  611.  
  612.   1. Do nothing.  Pretend g++ does implement automatic instantiation
  613.      management.  Code written for the Borland model will work fine, but
  614.      each translation unit will contain instances of each of the
  615.      templates it uses.  In a large program, this can lead to an
  616.      unacceptable amount of code duplication.
  617.  
  618.   2. Add `#pragma interface' to all files containing template
  619.      definitions.  For each of these files, add `#pragma implementation
  620.      "FILENAME"' to the top of some `.C' file which `#include's it.
  621.      Then compile everything with -fexternal-templates.  The templates
  622.      will then only be expanded in the translation unit which
  623.      implements them (i.e. has a `#pragma implementation' line for the
  624.      file where they live); all other files will use external
  625.      references.  If you're lucky, everything should work properly.  If
  626.      you get undefined symbol errors, you need to make sure that each
  627.      template instance which is used in the program is used in the file
  628.      which implements that template.  If you don't have any use for a
  629.      particular instance in that file, you can just instantiate it
  630.      explicitly, using the syntax from the latest C++ working paper:
  631.  
  632.           template class A<int>;
  633.           template ostream& operator << (ostream&, const A<int>&);
  634.  
  635.      This strategy will work with code written for either model.  If
  636.      you are using code written for the Cfront model, the file
  637.      containing a class template and the file containing its member
  638.      templates should be implemented in the same translation unit.
  639.  
  640.      A slight variation on this approach is to use the flag
  641.      -falt-external-templates instead; this flag causes template
  642.      instances to be emitted in the translation unit that implements
  643.      the header where they are first instantiated, rather than the one
  644.      which implements the file where the templates are defined.  This
  645.      header must be the same in all translation units, or things are
  646.      likely to break.
  647.  
  648.      *Note Declarations and Definitions in One Header: C++ Interface,
  649.      for more discussion of these pragmas.
  650.  
  651.   3. Explicitly instantiate all the template instances you use, and
  652.      compile with -fno-implicit-templates.  This is probably your best
  653.      bet; it may require more knowledge of exactly which templates you
  654.      are using, but it's less mysterious than the previous approach,
  655.      and it doesn't require any `#pragma's or other g++-specific code.
  656.      You can scatter the instantiations throughout your program, you
  657.      can create one big file to do all the instantiations, or you can
  658.      create tiny files like
  659.  
  660.           #include "Foo.h"
  661.           #include "Foo.cc"
  662.           
  663.           template class Foo<int>;
  664.  
  665.      for each instance you need, and create a template instantiation
  666.      library from those.  I'm partial to the last, but your mileage may
  667.      vary.  If you are using Cfront-model code, you can probably get
  668.      away with not using -fno-implicit-templates when compiling files
  669.      that don't `#include' the member template definitions.
  670.  
  671. 
  672. File: gcc.info,  Node: C++ Signatures,  Prev: Template Instantiation,  Up: C++ Extensions
  673.  
  674. Type Abstraction using Signatures
  675. =================================
  676.  
  677.    In GNU C++, you can use the keyword `signature' to define a
  678. completely abstract class interface as a datatype.  You can connect this
  679. abstraction with actual classes using signature pointers.  If you want
  680. to use signatures, run the GNU compiler with the `-fhandle-signatures'
  681. command-line option.  (With this option, the compiler reserves a second
  682. keyword `sigof' as well, for a future extension.)
  683.  
  684.    Roughly, signatures are type abstractions or interfaces of classes.
  685. Some other languages have similar facilities.  C++ signatures are
  686. related to ML's signatures, Haskell's type classes, definition modules
  687. in Modula-2, interface modules in Modula-3, abstract types in Emerald,
  688. type modules in Trellis/Owl, categories in Scratchpad II, and types in
  689. POOL-I.  For a more detailed discussion of signatures, see `Signatures:
  690. A C++ Extension for Type Abstraction and Subtype Polymorphism' by
  691. Gerald Baumgartner and Vincent F. Russo (Tech report CSD-TR-93-059,
  692. Dept. of Computer Sciences, Purdue University, December 1994, to appear
  693. in *Software Practice & Experience*).  You can get the tech report by
  694. anonymous FTP from `ftp.cs.purdue.edu' in `pub/reports/TR93-059.PS.Z'.
  695.  
  696.    Syntactically, a signature declaration is a collection of member
  697. function declarations and nested type declarations.  For example, this
  698. signature declaration defines a new abstract type `S' with member
  699. functions `int foo ()' and `int bar (int)':
  700.  
  701.      signature S
  702.      {
  703.        int foo ();
  704.        int bar (int);
  705.      };
  706.  
  707.    Since signature types do not include implementation definitions, you
  708. cannot write an instance of a signature directly.  Instead, you can
  709. define a pointer to any class that contains the required interfaces as a
  710. "signature pointer".  Such a class "implements" the signature type.
  711.  
  712.    To use a class as an implementation of `S', you must ensure that the
  713. class has public member functions `int foo ()' and `int bar (int)'.
  714. The class can have other member functions as well, public or not; as
  715. long as it offers what's declared in the signature, it is suitable as
  716. an implementation of that signature type.
  717.  
  718.    For example, suppose that `C' is a class that meets the requirements
  719. of signature `S' (`C' "conforms to" `S').  Then
  720.  
  721.      C obj;
  722.      S * p = &obj;
  723.  
  724. defines a signature pointer `p' and initializes it to point to an
  725. object of type `C'.  The member function call `int i = p->foo ();'
  726. executes `obj.foo ()'.
  727.  
  728.    Abstract virtual classes provide somewhat similar facilities in
  729. standard C++.  There are two main advantages to using signatures
  730. instead:
  731.  
  732.   1. Subtyping becomes independent from inheritance.  A class or
  733.      signature type `T' is a subtype of a signature type `S'
  734.      independent of any inheritance hierarchy as long as all the member
  735.      functions declared in `S' are also found in `T'.  So you can
  736.      define a subtype hierarchy that is completely independent from any
  737.      inheritance (implementation) hierarchy, instead of being forced to
  738.      use types that mirror the class inheritance hierarchy.
  739.  
  740.   2. Signatures allow you to work with existing class hierarchies as
  741.      implementations of a signature type.  If those class hierarchies
  742.      are only available in compiled form, you're out of luck with
  743.      abstract virtual classes, since an abstract virtual class cannot
  744.      be retrofitted on top of existing class hierarchies.  So you would
  745.      be required to write interface classes as subtypes of the abstract
  746.      virtual class.
  747.  
  748.    There is one more detail about signatures.  A signature declaration
  749. can contain member function *definitions* as well as member function
  750. declarations.  A signature member function with a full definition is
  751. called a *default implementation*; classes need not contain that
  752. particular interface in order to conform.  For example, a class `C' can
  753. conform to the signature
  754.  
  755.      signature T
  756.      {
  757.        int f (int);
  758.        int f0 () { return f (0); };
  759.      };
  760.  
  761. whether or not `C' implements the member function `int f0 ()'.  If you
  762. define `C::f0', that definition takes precedence; otherwise, the
  763. default implementation `S::f0' applies.
  764.  
  765. 
  766. File: gcc.info,  Node: Trouble,  Next: Bugs,  Prev: C++ Extensions,  Up: Top
  767.  
  768. Known Causes of Trouble with GNU CC
  769. ***********************************
  770.  
  771.    This section describes known problems that affect users of GNU CC.
  772. Most of these are not GNU CC bugs per se--if they were, we would fix
  773. them.  But the result for a user may be like the result of a bug.
  774.  
  775.    Some of these problems are due to bugs in other software, some are
  776. missing features that are too much work to add, and some are places
  777. where people's opinions differ as to what is best.
  778.  
  779. * Menu:
  780.  
  781. * Actual Bugs::              Bugs we will fix later.
  782. * Installation Problems::     Problems that manifest when you install GNU CC.
  783. * Cross-Compiler Problems::   Common problems of cross compiling with GNU CC.
  784. * Interoperation::      Problems using GNU CC with other compilers,
  785.                and with certain linkers, assemblers and debuggers.
  786. * External Bugs::    Problems compiling certain programs.
  787. * Incompatibilities::   GNU CC is incompatible with traditional C.
  788. * Fixed Headers::       GNU C uses corrected versions of system header files.
  789.                            This is necessary, but doesn't always work smoothly.
  790. * Standard Libraries::  GNU C uses the system C library, which might not be
  791.                            compliant with the ISO/ANSI C standard.
  792. * Disappointments::     Regrettable things we can't change, but not quite bugs.
  793. * C++ Misunderstandings::     Common misunderstandings with GNU C++.
  794. * Protoize Caveats::    Things to watch out for when using `protoize'.
  795. * Non-bugs::        Things we think are right, but some others disagree.
  796. * Warnings and Errors:: Which problems in your code get warnings,
  797.                          and which get errors.
  798.  
  799. 
  800. File: gcc.info,  Node: Actual Bugs,  Next: Installation Problems,  Up: Trouble
  801.  
  802. Actual Bugs We Haven't Fixed Yet
  803. ================================
  804.  
  805.    * The `fixincludes' script interacts badly with automounters; if the
  806.      directory of system header files is automounted, it tends to be
  807.      unmounted while `fixincludes' is running.  This would seem to be a
  808.      bug in the automounter.  We don't know any good way to work around
  809.      it.
  810.  
  811.    * The `fixproto' script will sometimes add prototypes for the
  812.      `sigsetjmp' and `siglongjmp' functions that reference the
  813.      `jmp_buf' type before that type is defined.  To work around this,
  814.      edit the offending file and place the typedef in front of the
  815.      prototypes.
  816.  
  817.    * There are several obscure case of mis-using struct, union, and
  818.      enum tags that are not detected as errors by the compiler.
  819.  
  820.    * When `-pedantic-errors' is specified, GNU C will incorrectly give
  821.      an error message when a function name is specified in an expression
  822.      involving the comma operator.
  823.  
  824.    * Loop unrolling doesn't work properly for certain C++ programs.
  825.      This is a bug in the C++ front end.  It sometimes emits incorrect
  826.      debug info, and the loop unrolling code is unable to recover from
  827.      this error.
  828.  
  829. 
  830. File: gcc.info,  Node: Installation Problems,  Next: Cross-Compiler Problems,  Prev: Actual Bugs,  Up: Trouble
  831.  
  832. Installation Problems
  833. =====================
  834.  
  835.    This is a list of problems (and some apparent problems which don't
  836. really mean anything is wrong) that show up during installation of GNU
  837. CC.
  838.  
  839.    * On certain systems, defining certain environment variables such as
  840.      `CC' can interfere with the functioning of `make'.
  841.  
  842.    * If you encounter seemingly strange errors when trying to build the
  843.      compiler in a directory other than the source directory, it could
  844.      be because you have previously configured the compiler in the
  845.      source directory.  Make sure you have done all the necessary
  846.      preparations.  *Note Other Dir::.
  847.  
  848.    * If you build GNU CC on a BSD system using a directory stored in a
  849.      System V file system, problems may occur in running `fixincludes'
  850.      if the System V file system doesn't support symbolic links.  These
  851.      problems result in a failure to fix the declaration of `size_t' in
  852.      `sys/types.h'.  If you find that `size_t' is a signed type and
  853.      that type mismatches occur, this could be the cause.
  854.  
  855.      The solution is not to use such a directory for building GNU CC.
  856.  
  857.    * In previous versions of GNU CC, the `gcc' driver program looked for
  858.      `as' and `ld' in various places; for example, in files beginning
  859.      with `/usr/local/lib/gcc-'.  GNU CC version 2 looks for them in
  860.      the directory `/usr/local/lib/gcc-lib/TARGET/VERSION'.
  861.  
  862.      Thus, to use a version of `as' or `ld' that is not the system
  863.      default, for example `gas' or GNU `ld', you must put them in that
  864.      directory (or make links to them from that directory).
  865.  
  866.    * Some commands executed when making the compiler may fail (return a
  867.      non-zero status) and be ignored by `make'.  These failures, which
  868.      are often due to files that were not found, are expected, and can
  869.      safely be ignored.
  870.  
  871.    * It is normal to have warnings in compiling certain files about
  872.      unreachable code and about enumeration type clashes.  These files'
  873.      names begin with `insn-'.  Also, `real.c' may get some warnings
  874.      that you can ignore.
  875.  
  876.    * Sometimes `make' recompiles parts of the compiler when installing
  877.      the compiler.  In one case, this was traced down to a bug in
  878.      `make'.  Either ignore the problem or switch to GNU Make.
  879.  
  880.    * If you have installed a program known as purify, you may find that
  881.      it causes errors while linking `enquire', which is part of building
  882.      GNU CC.  The fix is to get rid of the file `real-ld' which purify
  883.      installs--so that GNU CC won't try to use it.
  884.  
  885.    * On Linux SLS 1.01, there is a problem with `libc.a': it does not
  886.      contain the obstack functions.  However, GNU CC assumes that the
  887.      obstack functions are in `libc.a' when it is the GNU C library.
  888.      To work around this problem, change the `__GNU_LIBRARY__'
  889.      conditional around line 31 to `#if 1'.
  890.  
  891.    * On some 386 systems, building the compiler never finishes because
  892.      `enquire' hangs due to a hardware problem in the motherboard--it
  893.      reports floating point exceptions to the kernel incorrectly.  You
  894.      can install GNU CC except for `float.h' by patching out the
  895.      command to run `enquire'.  You may also be able to fix the problem
  896.      for real by getting a replacement motherboard.  This problem was
  897.      observed in Revision E of the Micronics motherboard, and is fixed
  898.      in Revision F.  It has also been observed in the MYLEX MXA-33
  899.      motherboard.
  900.  
  901.      If you encounter this problem, you may also want to consider
  902.      removing the FPU from the socket during the compilation.
  903.      Alternatively, if you are running SCO Unix, you can reboot and
  904.      force the FPU to be ignored.  To do this, type `hd(40)unix auto
  905.      ignorefpu'.
  906.  
  907.    * On some 386 systems, GNU CC crashes trying to compile `enquire.c'.
  908.      This happens on machines that don't have a 387 FPU chip.  On 386
  909.      machines, the system kernel is supposed to emulate the 387 when you
  910.      don't have one.  The crash is due to a bug in the emulator.
  911.  
  912.      One of these systems is the Unix from Interactive Systems: 386/ix.
  913.      On this system, an alternate emulator is provided, and it does
  914.      work.  To use it, execute this command as super-user:
  915.  
  916.           ln /etc/emulator.rel1 /etc/emulator
  917.  
  918.      and then reboot the system.  (The default emulator file remains
  919.      present under the name `emulator.dflt'.)
  920.  
  921.      Try using `/etc/emulator.att', if you have such a problem on the
  922.      SCO system.
  923.  
  924.      Another system which has this problem is Esix.  We don't know
  925.      whether it has an alternate emulator that works.
  926.  
  927.      On NetBSD 0.8, a similar problem manifests itself as these error
  928.      messages:
  929.  
  930.           enquire.c: In function `fprop':
  931.           enquire.c:2328: floating overflow
  932.  
  933.    * On SCO systems, when compiling GNU CC with the system's compiler,
  934.      do not use `-O'.  Some versions of the system's compiler miscompile
  935.      GNU CC with `-O'.
  936.  
  937.    * Sometimes on a Sun 4 you may observe a crash in the program
  938.      `genflags' or `genoutput' while building GNU CC.  This is said to
  939.      be due to a bug in `sh'.  You can probably get around it by running
  940.      `genflags' or `genoutput' manually and then retrying the `make'.
  941.  
  942.    * On Solaris 2, executables of GNU CC version 2.0.2 are commonly
  943.      available, but they have a bug that shows up when compiling current
  944.      versions of GNU CC: undefined symbol errors occur during assembly
  945.      if you use `-g'.
  946.  
  947.      The solution is to compile the current version of GNU CC without
  948.      `-g'.  That makes a working compiler which you can use to recompile
  949.      with `-g'.
  950.  
  951.    * Solaris 2 comes with a number of optional OS packages.  Some of
  952.      these packages are needed to use GNU CC fully.  If you did not
  953.      install all optional packages when installing Solaris, you will
  954.      need to verify that the packages that GNU CC needs are installed.
  955.  
  956.      To check whether an optional package is installed, use the
  957.      `pkginfo' command.  To add an optional package, use the `pkgadd'
  958.      command.  For further details, see the Solaris documentation.
  959.  
  960.      For Solaris 2.0 and 2.1, GNU CC needs six packages: `SUNWarc',
  961.      `SUNWbtool', `SUNWesu', `SUNWhea', `SUNWlibm', and `SUNWtoo'.
  962.  
  963.      For Solaris 2.2, GNU CC needs an additional seventh package:
  964.      `SUNWsprot'.
  965.  
  966.    * On Solaris 2, trying to use the linker and other tools in
  967.      `/usr/ucb' to install GNU CC has been observed to cause trouble.
  968.      For example, the linker may hang indefinitely.  The fix is to
  969.      remove `/usr/ucb' from your `PATH'.
  970.  
  971.    * If you use the 1.31 version of the MIPS assembler (such as was
  972.      shipped with Ultrix 3.1), you will need to use the
  973.      -fno-delayed-branch switch when optimizing floating point code.
  974.      Otherwise, the assembler will complain when the GCC compiler fills
  975.      a branch delay slot with a floating point instruction, such as
  976.      `add.d'.
  977.  
  978.    * If on a MIPS system you get an error message saying "does not have
  979.      gp sections for all it's [sic] sectons [sic]", don't worry about
  980.      it.  This happens whenever you use GAS with the MIPS linker, but
  981.      there is not really anything wrong, and it is okay to use the
  982.      output file.  You can stop such warnings by installing the GNU
  983.      linker.
  984.  
  985.      It would be nice to extend GAS to produce the gp tables, but they
  986.      are optional, and there should not be a warning about their
  987.      absence.
  988.  
  989.    * In Ultrix 4.0 on the MIPS machine, `stdio.h' does not work with GNU
  990.      CC at all unless it has been fixed with `fixincludes'.  This causes
  991.      problems in building GNU CC.  Once GNU CC is installed, the
  992.      problems go away.
  993.  
  994.      To work around this problem, when making the stage 1 compiler,
  995.      specify this option to Make:
  996.  
  997.           GCC_FOR_TARGET="./xgcc -B./ -I./include"
  998.  
  999.      When making stage 2 and stage 3, specify this option:
  1000.  
  1001.           CFLAGS="-g -I./include"
  1002.  
  1003.    * Users have reported some problems with version 2.0 of the MIPS
  1004.      compiler tools that were shipped with Ultrix 4.1.  Version 2.10
  1005.      which came with Ultrix 4.2 seems to work fine.
  1006.  
  1007.      Users have also reported some problems with version 2.20 of the
  1008.      MIPS compiler tools that were shipped with RISC/os 4.x.  The
  1009.      earlier version 2.11 seems to work fine.
  1010.  
  1011.    * Some versions of the MIPS linker will issue an assertion failure
  1012.      when linking code that uses `alloca' against shared libraries on
  1013.      RISC-OS 5.0, and DEC's OSF/1 systems.  This is a bug in the
  1014.      linker, that is supposed to be fixed in future revisions.  To
  1015.      protect against this, GNU CC passes `-non_shared' to the linker
  1016.      unless you pass an explicit `-shared' or `-call_shared' switch.
  1017.  
  1018.    * On System V release 3, you may get this error message while
  1019.      linking:
  1020.  
  1021.           ld fatal: failed to write symbol name SOMETHING
  1022.            in strings table for file WHATEVER
  1023.  
  1024.      This probably indicates that the disk is full or your ULIMIT won't
  1025.      allow the file to be as large as it needs to be.
  1026.  
  1027.      This problem can also result because the kernel parameter `MAXUMEM'
  1028.      is too small.  If so, you must regenerate the kernel and make the
  1029.      value much larger.  The default value is reported to be 1024; a
  1030.      value of 32768 is said to work.  Smaller values may also work.
  1031.  
  1032.    * On System V, if you get an error like this,
  1033.  
  1034.           /usr/local/lib/bison.simple: In function `yyparse':
  1035.           /usr/local/lib/bison.simple:625: virtual memory exhausted
  1036.  
  1037.      that too indicates a problem with disk space, ULIMIT, or `MAXUMEM'.
  1038.  
  1039.    * Current GNU CC versions probably do not work on version 2 of the
  1040.      NeXT operating system.
  1041.  
  1042.    * On NeXTStep 3.0, the Objective C compiler does not work, due,
  1043.      apparently, to a kernel bug that it happens to trigger.  This
  1044.      problem does not happen on 3.1.
  1045.  
  1046.    * On the Tower models 4N0 and 6N0, by default a process is not
  1047.      allowed to have more than one megabyte of memory.  GNU CC cannot
  1048.      compile itself (or many other programs) with `-O' in that much
  1049.      memory.
  1050.  
  1051.      To solve this problem, reconfigure the kernel adding the following
  1052.      line to the configuration file:
  1053.  
  1054.           MAXUMEM = 4096
  1055.  
  1056.    * On HP 9000 series 300 or 400 running HP-UX release 8.0, there is a
  1057.      bug in the assembler that must be fixed before GNU CC can be
  1058.      built.  This bug manifests itself during the first stage of
  1059.      compilation, while building `libgcc2.a':
  1060.  
  1061.           _floatdisf
  1062.           cc1: warning: `-g' option not supported on this version of GCC
  1063.           cc1: warning: `-g1' option not supported on this version of GCC
  1064.           ./xgcc: Internal compiler error: program as got fatal signal 11
  1065.  
  1066.      A patched version of the assembler is available by anonymous ftp
  1067.      from `altdorf.ai.mit.edu' as the file
  1068.      `archive/cph/hpux-8.0-assembler'.  If you have HP software support,
  1069.      the patch can also be obtained directly from HP, as described in
  1070.      the following note:
  1071.  
  1072.           This is the patched assembler, to patch SR#1653-010439, where
  1073.           the assembler aborts on floating point constants.
  1074.  
  1075.           The bug is not really in the assembler, but in the shared
  1076.           library version of the function "cvtnum(3c)".  The bug on
  1077.           "cvtnum(3c)" is SR#4701-078451.  Anyway, the attached
  1078.           assembler uses the archive library version of "cvtnum(3c)"
  1079.           and thus does not exhibit the bug.
  1080.  
  1081.      This patch is also known as PHCO_4484.
  1082.  
  1083.    * On HP-UX version 8.05, but not on 8.07 or more recent versions,
  1084.      the `fixproto' shell script triggers a bug in the system shell.
  1085.      If you encounter this problem, upgrade your operating system or
  1086.      use BASH (the GNU shell) to run `fixproto'.
  1087.  
  1088.    * Some versions of the Pyramid C compiler are reported to be unable
  1089.      to compile GNU CC.  You must use an older version of GNU CC for
  1090.      bootstrapping.  One indication of this problem is if you get a
  1091.      crash when GNU CC compiles the function `muldi3' in file
  1092.      `libgcc2.c'.
  1093.  
  1094.      You may be able to succeed by getting GNU CC version 1, installing
  1095.      it, and using it to compile GNU CC version 2.  The bug in the
  1096.      Pyramid C compiler does not seem to affect GNU CC version 1.
  1097.  
  1098.    * There may be similar problems on System V Release 3.1 on 386
  1099.      systems.
  1100.  
  1101.    * On the Intel Paragon (an i860 machine), if you are using operating
  1102.      system version 1.0, you will get warnings or errors about
  1103.      redefinition of `va_arg' when you build GNU CC.
  1104.  
  1105.      If this happens, then you need to link most programs with the
  1106.      library `iclib.a'.  You must also modify `stdio.h' as follows:
  1107.      before the lines
  1108.  
  1109.           #if     defined(__i860__) && !defined(_VA_LIST)
  1110.           #include <va_list.h>
  1111.  
  1112.      insert the line
  1113.  
  1114.           #if __PGC__
  1115.  
  1116.      and after the lines
  1117.  
  1118.           extern int  vprintf(const char *, va_list );
  1119.           extern int  vsprintf(char *, const char *, va_list );
  1120.           #endif
  1121.  
  1122.      insert the line
  1123.  
  1124.           #endif /* __PGC__ */
  1125.  
  1126.      These problems don't exist in operating system version 1.1.
  1127.  
  1128.    * On the Altos 3068, programs compiled with GNU CC won't work unless
  1129.      you fix a kernel bug.  This happens using system versions V.2.2
  1130.      1.0gT1 and V.2.2 1.0e and perhaps later versions as well.  See the
  1131.      file `README.ALTOS'.
  1132.  
  1133.    * You will get several sorts of compilation and linking errors on the
  1134.      we32k if you don't follow the special instructions.  *Note
  1135.      Configurations::.
  1136.  
  1137.    * A bug in the HP-UX 8.05 (and earlier) shell will cause the fixproto
  1138.      program to report an error of the form:
  1139.  
  1140.           ./fixproto: sh internal 1K buffer overflow
  1141.  
  1142.      To fix this, change the first line of the fixproto script to look
  1143.      like:
  1144.  
  1145.           #!/bin/ksh
  1146.  
  1147.